Это воркшоп на 2.5-3 часа. Раз на прошлом ЛАФе он выиграл приз зрительских симпатий, то почему бы его и не повторить (:

Расскажу о сообществе аналитиков Санкт-Петербурга:

•  принципы и ценности
•  как оно возникло,
•  как развивалось,
• наши достижения,
•  как сейчас работает:
  • процессы и взаимодействия
  • люди.

Расскажу о принципах успешных компаний, которые не конкурируют в кровавом море, а находят свою нишу на просторах голубого океана.

Покажу инструменты, которые работают для нахождения тех самых тихих заводей, где можно отрыть успешный бизнес.

По сути этот подход является одним из методов бизнес-анализа, который помогает найти новые успешные направления работы компании или продукты.

В докладе будут раскрыты следующие темы:

1. Отличие кровавого моря от голубого океана

2. Метод разработки стратегии голубого океана

3. Методы выхода за привычные границы рынка

У всякого клиента есть проблема, но часто он просит фичи, а не решение проблемы. Или он уже решил, что ему может помочь, а когда продукт выпускается, оказывается что результат не тот. Как бы сделать так, чтобы клиент сам рассказал о проблемах, и мы смогли сформровать более эфективное предложение ценности в виде функцинала?

На этот вопрос и попробуем найти ответ.

Аналитик, как посредник между заказчиком и командой, может выступать в роли Владельца продукта. Но команда сама отвечает за проектирование решения и архитектуру. Находясь внутри команды сложно заметить проблемы выбранных архитектурных решений и препяствия  для реализации новых историй.

Поговорим о том, как можно помочь команде выявить ошибки, до того как она их совершит. (Доклад/ Мастер-класс)

Доклад посвящен подходу к обеспечению достоверности финансовой информации в организации. В докладе будут рассмотрены:

• признаки недостоверности финансовой информации;
• способ верификации финансовой информации;
• устройство процесса достоверного информирования;
• подход к построению такого процесса.

На круглом столе поговорим о планировании работ аналитиков, об оценке трудозатрат, сроках выполнения.

Как Вы расчитываете трудозатраты? Как определяете сроки выполнения? Есть ли методики расчета или используете экспертные оценки? Какова необходимая точность расчетов? Что делаете, если работы растягиваются, сроки нарушаются, возникают дополнительные работы?

Почему аналитики не любят оценку трудозатрат? Почему не любим указать сроки? Можно ли превратить оценку трудозатрат и сроков из дамоклова меча в помощника?

Рассмотрим наиболее распространенные методики оценки трудозатрат. И поделюсь успешным опытом (около 10 лет) планирования работ аналитиков. 

Оформление проектного опыта, знаний и результатов работы сотрудников - основа базы знаний (далее - БЗ) для компании. Её использование снижает риски и экономит ресурсы. Доклад посвящен опыту аналитиков нашей компании в формировании БЗ.

В первой части доклада расскажу о нашем хранилище проектной документации на основе платформы MS SharePoint и DocTrix. Оно содержит проектную документацию, разработанную аналитиками, и наполняется при завершении проекта. Наш подход полезен тем, что мы организовали удобный поиск документов за счет их категоризации по типам, доменам, модулям информационных систем.

Во второй части доклада расскажу об оформлении ретроспектив по проектам в виде статей. Ретроспектива позволяет понять, насколько правильно реализовывался проект и какие получены уроки, сформировать перечень ошибок и «выстреливших» рисков, которые требуется учитывать и избегать в будущем. Также статьи содержат информацию об инструментах, стандартах документации, аспектах работы в конкретном домене.

При разработке сценариев использования любой системы часто используется следующая модель: в центре картины мира - разрабатываемая система, предоставляющая свой функционал пользователям и другим системам. Это полезное для анализа упрощение ситуации, если не забывать о том, при каких предположениях это упрощение было сделано. 

В реальной жизни пользователи, кроме разрабатываемой системы, часто одновременно взаимодействуют и с несколькими другими системами. Иногда, поместив в центр диаграммы конкретного пользователя и проследив все его взаимодействия, можно открыть для себя совершенно другие юзкейзы, и прийти к совсем другим требованиям. 

Разберем это на примере драматического случая использования информационной системы обработки данных спутникового треккинга при наступлении неучтенных ее разработчиками юзкейзов.

ПО постоянно изменяется. Выходят минорные обновления, патчи, баг-фиксы, крупные обновления, новые версии и релизы. Разработчикам хочется похвастаться тем, что они сделали, а пользователям прочитать о том, что же изменилось в продукте.

Мы начали писать release notes (заметки к релизу с описанием изменений) для своего продукта 5 лет назад. И были горды собой — выносили в relese notes только главные задачи, указывали их номер в JIRA вместе со ссылкой, писали подробную инструкцию, как перейти на новый релиз.

Но потом мы заметили, что заказчики не используют новые возможности. Стали выяснить, почему? Оказалось — они про них не знают! Мы расстроились, задумались, а потом переработали формат описания изменений с нуля. И это сработало!

Приглашаю аналитиков и технических писателей послушать о том, как мы добились того, чтобы заказчики были в курсе изменений, и как новый формат relese notes повлиял на весь процесс разработки новых релизов.